Web sites, or Internet sites, often provide information, products, services, and the like to their users. Many web sites require a user to “register” before their web servers will grant access to the user. During registration, a user typically supplies personal information such as username, account number, address, telephone number, e-mail address, computer platform, age, gender, and/or hobbies to the registering web site. The registration information may be necessary to complete transactions (e.g., commercial or financial transactions). Typically, the information also permits the web site to contact the user directly (e.g., via electronic mail) to announce, for example, special promotions, new products, or new web site features. Additionally, web sites often collect user information so web site operators can better target future marketing activities or adjust the content provided by the sites.
When registering a user for the first time, a web site may request that the user select a login identifier, or login ID, and an associated password. The login ID allows the web site to identify the user and retrieve information about the user during subsequent user visits to the web site. Generally, the login ID is unique to the web site such that no two users have the same login ID. The combination of the login ID and password associated with the login ID allows the web site to authenticate the user during subsequent visits to the web site. The password also prevents others (who do not know the password) from accessing the web site using the user's login ID. This password protection is particularly important if the web site stores private or confidential information about the user, such as financial information or medical records.
Using a presently available multi-site user authentication system, a web user can maintain a single login ID (and associated password) for accessing multiple, affiliated web servers or services. Such a system permits the user to establish a unique account identified by, for example, an e-mail address.
Large Internet service providers often have many different web sites through which they offer services to consumers. Moreover, a single web service can actually be made up of many different content providers. Other sites may be used to provide content related to children's interests, e-shopping, news, and so forth. Consumers usually perceive these related sites as being essentially the same service. Further, as Internet usage migrates to a subscription-based model that includes content and services from a variety of different sites, the need exists for automatically authenticating a user for related sites and accurately sharing common information (e.g., billing and subscription information) between related sites.
As described above, a web site often gathers personal information about its users for later use. A typical privacy statement for a web site describes how the site protects and uses personal information. The policy will likely specify first what information the site collects. For example, the site may maintain a profile for the user including information such as the user's e-mail address, first and last name, country or region, state or territory, ZIP code or postal code, language preference, time zone, gender, birth date, occupation, telephone number(s), credit card information, billing and shipping addresses, password, PIN, secret question and secret answer, clothing sizes, music preferences, and the like. Inasmuch as this profile information can be quite sensitive, the typical policy also specifies how the information will or will not be used. For example, a web site's privacy policy may forbid the site from selling or renting a user's personal information without prior consent. The same policy, however, may detail a number of permitted uses (e.g., resolving customer support inquiries, performing statistical analyses of the site's services, conforming to legal requirements, protecting the personal safety of users or the public). A typical policy often specifies certain circumstances under which disclosures or uses of information are permitted and those other circumstances under which they are not.
Presently, there exist systems and methods for automatically authenticating a user for access to a site or service if the user has previously signed in to another site or service. Such prior systems and methods automatically sign in the user to the latter site or service by performing a “silent” authentication, i.e., signing in the user to the latter site or service without re-asking for user credentials (e.g., login ID and password).
As one particular example of the prior systems and methods, a user may navigate to a first selected service, namely, Service A, by using a browser of a client computer. If the user is not already signed in to Service A, Service A may provide a link on the web page for the user to sign in to Service A. When the user clicks on this link, he or she is redirected to a web page hosted by an authentication server, at which point the authentication server prompts the user for his or her user credentials. Since the user is forced to submit his or her user credentials, such prompting for credentials is referred to as a “hard authentication.” If the submitted user credentials have been successfully authenticated, the authentication server may issue a cookie in the domain of the authentication server, which includes an encrypted authentication ticket that authenticates the user. This encrypted authentication ticket may contain a simple “access” token, which verifies that the user is who he or she claims to be. It also may contain some of the “profile” data. The authentication server then stores this cookie, which is in the domain of the authentication server, on the client computer and redirects the browser to a return uniform resource locator (URL) in the domain of Service A. This return URL includes several parameters on its query string, including a parameter that specifies the authentication ticket encrypted specifically to Service A as well as operational parameters specific to Service A. After the browser is redirected to the return URL of Service A, Service A may use the query string parameters to issue a cookie written in its own domain and store this cookie on the client computer. Again, this cookie may contain both the simple access token and some encrypted form of the profile data.
And in this example, the user may later use the browser to navigate to Service B. If Service A and Service B are in the same domain and if the user is still signed in to Service A, then Service B can silently redirect the user to the authentication server to sign in the user to itself. But if the user is no longer signed in to Service A, then the user would be forced by Service B to provide his or her user credentials (i.e., by performing a hard authentication), which may not be an acceptable user experience from the perspective of Service B.
As can be seen in this example, even though the prior systems and methods allow the user to be “silently” signed in to Service B (i.e., signing in without resubmitting the user credentials), such “silent” authentication is limited to situations where Service A and Service B are within the same domain and situations where performing a hard authentication to sign in the user is acceptable to Service B when the user is not already signed in to Service A). This is because cookies are domain-specific, and accordingly, sites or services in one domain may not access cookies issued by sites or services in a different domain. For various reasons, many of the sites or services owned by a service provider may be in different domains, even though it is clear to the users that they are affiliated. Some examples of such situations include sites or services in international domains. Also, many sites or services today may not desire to force a hard authentication on a user if it is unnecessary but would prefer to obtain the user's credentials if they are already available from another authentication transaction.
Currently, there are several approaches to authenticate a user when Service A and Service B are in different domains and when Service B does not wish to perform a hard authentication on the user. In one approach, the return URL of the destination site, namely, Service B, may include a special parameter that indicates the sign-in status of the user at the calling site, namely, Service A. Service B can then perform a “silent” authentication for the user. This may involve some logic on Service A to pass this special parameter to Service B and some logic on Service B to respond to this special parameter. In addition, since most cross-site links direct users through a central redirect server, this central redirect server may detect the sign-in status of the user at Service A and handle the necessary sign-in to Service B. Problems of this approach, however, are that it is difficult to implement links with special parameters and that it requires special coordination between Service A and Service B. And this approach does not address cases where the user navigates to Service B directly or through a link in a hotlist, bookmark list, or Favorites folder (i.e., without clicking a link on a web page of Service A that directs to Service B).
In another approach, after the user is signed in to Service A, the post sign-in web page of Service A may include some logic to determine an alternate domain, in this case Service B, and get the user signed in to the alternate domain. But this approach requires sites or services to implement extra logic on their post sign-in web pages. It also requires services to be aware of the alternate domains to perform this post-processing and accordingly is error-prone. And there lacks a consistent technique for determining whether a particular site or service is the alternate domain of another site or service.
In yet another approach, if the user is signed in to Service A, Service A can get the user signed in to Service B by first redirecting the user to a web page of Service B, signing in the user for Service B via the authentication server, and then redirecting the user back to Service A. A cookie is then issued in the domain of Service A to indicate that the sign-in for Service B was performed. In an alternative approach, after the user navigates to Service B and after Service B determines that the user is not signed in to Service B, Service B may check if the user is signed in to an alternate domain, i.e., Service A. Specifically, Service B may check with Service A to see if the user is signed in to Service A. Service A would then check if the user is signed in to itself, and if so, get the user signed in to Service B via the authentication server. The problem of this approach is that if the user is not signed in to Service A, it is difficult to avoid having the sign-in status checked for most web pages of Service A. This may cause significantly increased rendering time for the user. And the services would need to implement extra logic in order to sign in the user to an alternate domain. This may be prohibitive for large service providers and may be error-prone. Such an approach also does not perform well when there are multiple domains in the same group because checking with each one of the multiple domains is not practical.
As can be seen in the described approaches, the user is required to access the authentication server again when attempting to sign in to an alternate domain even though he or she has already been authenticated by the authentication server. This generates an extra set of server redirects and, as a result, decreases the response time of the authentication server and increases the latency for the user to sign in. Prior systems and methods further fail to allow sites to implement cross-domain authentication that does not request available user credentials without cumbersome coding and coordination between the sites. The failure of the prior systems and methods to provide effective cross-domain authentication thus impairs users' expectations that a single login ID automatically provides access to multiple, affiliated sites and services even if they are in different domains.
Accordingly, a solution is needed that effectively provides a user access to sites or services across different domains while complying with a set of business rules and without requesting available user credentials.